Search Results: "Ritesh Raj Sarraf"

I am pleased to announce the release of apt-offline - 1.6 This release is mostly a bug fix release, which every user should upgrade to. It also fixes a major bug in the way we limited the validation of GPG integrity, for the APT repository lists (Thank you Paul Wise). Also, In the last release, we migrated from custom magic library to the python shipped ctype python-magic library. That allowed some bugs to creep, and hopefully now, all those bugs should be fixed. A big thanks to Roland Summers for his bug reports and continuous feedback. What is apt-offline ?

Description-en: offline APT package manager
 apt-offline is an Offline APT Package Manager.
 .
 apt-offline can fully update and upgrade an APT based distribution without
 connecting to the network, all of it transparent to APT.
 .
 apt-offline can be used to generate a signature on a machine (with no network).
 This signature contains all download information required for the APT database
 system. This signature file can be used on another machine connected to the
 internet (which need not be a Debian box and can even be running windows) to
 download the updates.
 The downloaded data will contain all updates in a format understood by APT and
 this data can be used by apt-offline to update the non-networked machine.
 .
 apt-offline can also fetch bug reports and make them available offline.

Debian changelog for the 1.6 release.

apt-offline (1.6) experimental; urgency=medium
  * [2a4a7f1] Don't abuse exception handlers.
    Thanks to R-Sommer
  * [afc51b3] MIME type for a deb package.
    Thanks to R-Sommer
  * [ec2d539] Also include debian-archive-keyring.
    Thanks to Hans-Christoph Steiner (Closes: #748082)
  * [dc602ac] Update MIME type for .gpg
  * [c4f9b71] Cycle through possible apt keyrings.
    Thanks to Paul Wise (Closes: #747163)
  * [de0fe4d] Clarify manpage for install
  * [b5e1075] Update manpage with some doc about argparse positional
    values to arguments
  * [c22d64d] Port is data type integer.
    Thanks to Roland Sommer
  * [67edebe] autodetect release name
  * [5803141] Disable python-apt support
 -- Ritesh Raj Sarraf <rrs@debian.org>  Wed, 14 Jan 2015 15:34:45 +0530

[1] https://alioth.debian.org/projects/apt-offline/

Categories:
Debian-Blog
Tools

Keywords:
apt-offline

RHUT

Dear Lazy Web, I have an HP Envy J104TS laptop. Recently I saw an interesting message in the kernel log. [99360.969652] [Firmware Bug]: battery: (dis)charge rate invalid. Does anybody know what firmware is it referring to here ? I don't think the current set of firmwares shiped by linux are involved in battery related information. Is it the BIOS ?

[95474.561491] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[95474.803578] r8169 0000:0f:00.0 eth0: link down
[95474.803627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[95474.933797] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[95477.111599] wlan0: authenticate with 00:03:7f:fe:00:02
[95477.127389] wlan0: send auth to 00:03:7f:fe:00:02 (try 1/3)
[95477.129315] wlan0: authenticated
[95477.131352] wlan0: associate with 00:03:7f:fe:00:02 (try 1/3)
[95477.133605] wlan0: RX AssocResp from 00:03:7f:fe:00:02 (capab=0x411 status=0 aid=3)
[95477.133686] wlan0: associated
[95477.133703] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[99125.123138] device vethNLAABF entered promiscuous mode
[99125.123377] IPv6: ADDRCONF(NETDEV_UP): vethNLAABF: link is not ready
[99125.188568] IPv6: ADDRCONF(NETDEV_CHANGE): vethNLAABF: link becomes ready
[99125.188615] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99125.188631] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99140.239301] lxcbr0: port 1(vethNLAABF) entered forwarding state
[99360.969652] [Firmware Bug]: battery: (dis)charge rate invalid.
[99361.729291] NMI watchdog: enabled on all CPUs, permanently consumes one hw-PMU counter.
[99361.864205] EXT4-fs (dm-2): re-mounted. Opts: errors=remount-ro,data=writeback,commit=0
[99361.905210] EXT4-fs (sda6): re-mounted. Opts: data=ordered,commit=0
[102236.267648] lxcbr0: port 1(vethNLAABF) entered disabled state
[102236.556452] lxcbr0: port 1(vethNLAABF) entered disabled state
[102236.557476] device vethNLAABF left promiscuous mode
[102236.557483] lxcbr0: port 1(vethNLAABF) entered disabled state

Categories:
Debian-Blog

Keywords:
firmware
battery

RHUT

Linux has improved many many things over the last couple of years. Of the many improvements, the one that I've started leveraging the most today, are Control Groups. In the past, when there was a need to build a prototype for a solution, we needed hardware. Then came the virtualization richness to Linux. It came in 2 major flavors, KVM (Full Virtualization) and Xen (Para Virtualization). Over the years, the difference of para vs full, for both the implementations, is almost none. KVM now has support for Para-Virtualizaiton, with para-virtualized drviers for most resource intensive tasks, like network and I/O. Similarly, Xen has Full Virtualization support with the help of Qemu-KVM. But, if you had to build a prototype implementation comprising of a multi node setup, virtualization could still be resource hungry. Otherwise too, if your focus was an application (say like a web framework), virtualization was an overkill. All thanks to Linux Containers, prototyping applicaiton based solutions, is now a breeze in Linux. The LXC project is very well designed, and well balanced, in terms of features (as compared to the recently introduced Docker implementation). From an application's point of view, linux containers provide virtualization for namespace, network and resources. Thus making more than 90% of your application's needs fulfilled. For some apps, where a dependency on the kernel is needed, linux containers will not serve the need. Beyond the defaults provided by the distribution, I like to create a base container with my customizations, as a template. This allows me to quickly create environements, without too much housekeeping to do for the initial setup. My base config, looks like:

rrs@learner:~$ sudo cat /var/lib/lxc/deb-template/config
[sudo] password for rrs:
# Template used to create this container: /usr/share/lxc/templates/lxc-debian
# Parameters passed to the template:
# For additional config options, please look at lxc.container.conf(5)
# CPU
lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234
# Mem
lxc.cgroup.memory.limit_in_bytes = 2000M
lxc.cgroup.memory.soft_limit_in_bytes = 1500M
# Network
lxc.network.type = veth
lxc.network.hwaddr = 00:16:3e:0c:c5:d4
lxc.network.flags = up
lxc.network.link = lxcbr0
# Root file system
lxc.rootfs = /var/lib/lxc/deb-template/rootfs
# Common configuration
lxc.include = /usr/share/lxc/config/debian.common.conf
# Container specific configuration
lxc.mount = /var/lib/lxc/deb-template/fstab
lxc.utsname = deb-template
lxc.arch = amd64
# For apt
lxc.mount.entry = /var/cache/apt/archives var/cache/apt/archives none defaults,bind 0 0
23:07          
rrs@learner:~$

Some of the important settings to have in the templace are the mount point, to point to your local apt cache, and CPU and Memory limits. If there was one feature request to ask the LXC developers, I'd ask them to provide a util-lxc tools suite. Currently, to know the memory (soft/hard) allocation for the container, one needs to do the following:

rrs@learner:/sys/fs/cgroup/memory/lxc/deb-template$ cat memory.soft_limit_in_bytes memory.limit_in_bytes
1572864000
2097152000
23:21          
rrs@learner:/sys/fs/cgroup/memory/lxc/deb-template$ bc
bc 1.06.95
Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type  warranty'.
1572864000/1024/1024
1500
quit
23:21          
rrs@learner:/sys/fs/cgroup/memory/lxc/deb-template$

Tools like lxc-cpuinfo, lxc-free would be much better. Finally, there's been a lot of buzz about Docker. Docker is an alternate product offering, like LXC, for Linux Containers. From what I have briefly looked at, docker doesn't seem to be providing any ground breaking new interface than what is already possible with LXC. It does take all the tidbit tools, and presents you with a unified docker interface. But other than that, I couldn't find it much appealing. And the assumption that the profiles should be pulled off the internet (Github ?) is not very exciting. I am hoping they do have other options, where dependence on the network is not really required.

Categories:
Debian-Blog
Computing
Technology
Virtualization

Keywords:
docker
lxc
linux containers
virtualization

RHUT

We are almost at the end of 2014. While 2014 has been a year with many mixed experiences, I think it does warrant one blog entry ;-) Recently, I've again started spending more time on Linux products / solutions, than spending time focused on a specfic subsystem. This change has been good. It has allowed me to re-cap all the advancements that have happened in the Linux world, umm... in the last 5 years. Once upon a time, the Linux kernel sucked on the Desktop. It led to many desktop improvement related initiatives. Many accepted in kernel, while others stood as it is (out-of-tree) still as of today. Over the years, there are many people that advocate for such out-of-tree features, for example the -ck patchset, claiming it has better performance. Most of the times, these are patches not carried by your distribution vendor, which leads you to alternate sources, if you want to try. Having some spare time, I tried the Alternative Kernel project. It is nothing but a bunch of patchsets, on top of the stock kernel. After trying it out, I must say that these patchsets are out-of-tree, for good. I hardly could make out any performance gain. But I did notice a considerable increase in the power consumption. On my stock Debian kernel, the power consumption lies around 15-18 W. That increased to 20+ W on the alternate kernels. I guess most advocates for the out-of-tree patchsets, only measure the 1-2% performance gain, where as completely neglect the fact that that kernel sleeps less often. But back to the generic Linux kernel performance problem...... Recently, in the last 2 years, the performance suckiness of the Linux kernel is hardly noticed. So what changed ? The last couple of years have seen a rise in high capacity RAM, at affordable consumer price. 8 - 16 GiB of RAM is common on laptops these days. If you go and look at the sucky bug report linked above, it is marked as closed, justified Working as Designed. The core problem with the bug reported, has to do with slow media. The Linux scheduler is (in?)efficient. It works hard to give you the best throughput and performance (for server workloads). I/O threads are a high priority task in the Linux kernel. Now map this scene to the typical Linux desktop. If you end up with doing too much buffered I/O, thus exhausting all your available cache, and trigger paging, you are in for some sweet experience. Given that the kernel highly priotizes I/O tasks, and if your underneath persistent storage device is slow (which is common if you have an external USB disk, or even an internal rotating magnetic disk), you end up blocking all your CPU cycles against the slow media. Which further leads to no available CPU cycles for your other desktop tasks. Hence, when you do I/O at such level, you find your desktop go terribly sluggish. It is not that your CPU is slow or in-capable. It is just that all your CPU slices are blocked. Blocked waiting for your write() to report a completion. So what exactly changed that we don't notice that problem any more ????

RAM - Increase in RAM has led to more I/O be accommodated in cache. The best way to see this in action is to do a copy of a large file, something almost equivalent to the amount of RAM you have. But make sure it is less than the overall amount. For example, if you have 4 GiB of RAM, try copying a file of size 3.5 GiB in your graphical file manager. And at the same time, on the terminal, keep triggering the sync command. Check how long does it take for the sync to complete. By being able to cache large amount of data, the Linux kernel has been better at improving the overall performance in the eyes of the user.
File System - But RAM is not alone. The file system has played a very important role too. Earlier, with ext3 file system, we had a commit interval of (5?) 30 seconds. That led to the above mentioned sync equivalent to get triggered every 30 secs. It was a safety measure to ensure, that at worst, you lose 30 secs worth of data. But it did hinder performance. With ext4, came delayed allocation. Delayed Allocation allowed the write() to return immediate while the data was in cache, and deferred the task of actual write() to the file system. This allowed for the allocator to find the best contiguous slot for the data to be written. Thus it improved the file system. It also brough corruption for some of the apps. :-)
Solid State Drives - The file system and RAM alone aren't the sole factors that led to the drastic improvement in the overall experience of the Linux desktop. If you read through the bug report linked in this article, you'll find the core root cause to be slow persistent storage devices. Could the allocator have been improved (like Windows) to not be so pressing of the Linux desktop ? Maybe, yes. But that was a decision for the kernel devs and they believed (and believe) to keep those numbers to minimum. Thus for I/O, as for today, you have 3 schedulers and for CPU, just 1. What dramatically improved the overall Linux Desktop performance was the general availability of solid state devices. These device are real fast, which in effect made the write() calls return immediate, and did not block the CPU.

So, it was the advancement in both hardware and software that led to better overall desktop performance. Does the above mentioned bug still exist ? Yes. Its just that it is much harder to trigger it now. You'll have to ensure that you max out your cache and trigger paging. And then try to do ask for some CPU cycles. But it wasn't that back then we didn't use Linux on the desktop / laptop. It sure did suck more than, say, Windows. But hey, sometimes we have to eat our own dog food. Even then, there sure were some efforts to overcome the then limitations. The first and obvious one is the out-of-tree patchset. But ther were also some other efforts to improve the situation. The first such effort, that I can recollect, was ulatency. With Linux adding support for Control Groups, there were multiple avenues open on how to tackle and tame the resource starvation problem. The crux of the problem was that Linux gave way too much priority to the I/O tasks. I still wish Linux has a profile mechanism, where in on the kernel command line, we could specify what profile should Linux boot into. Anyways, with ulatency, we saw improvements in the Linux Desktop experience. ulatency had in-built policies to whitelist / blacklist a set of profiles. For example, KDE was a profile. Thus, ulatency would club all KDE processes into a group and give that group a higher precedence to ensure that it had its fair share of CPU cycles. Today, at almost the end of 2014, there are many more consumer of Linux's control groups. Prominent names would be: LXC and systemd. ulatency has hardly seen much development in the last year. Probably it is time for systemd to take over. systemd is expected to bring lots of features to the Linux world, thus bridging the (many) gap Linux has had on the desktop. It makes extensive use of Control Groups for a variety of (good) reasons, which has led it to be a linux-only product. I think it should have never marketed itself as the init daemon. It rather fits better when called as the System Management Daemon. The path to Linux Desktop looks much brighter in 2015 and beyond thanks to all the advancements that have happened so far. The other important players, who should be thanked are Mobile and Low Latency products (Android, ChromeBook), whose engagement to productize Linux has led to better features overall.

Categories:
Debian-Blog
Computing

Keywords:
linux
kernel
desktop
linux containers

RHUT

I am pleased to announce the release of Laptop Mode Tools at version 1.66. This release fixes an important bug in the way Laptop Mode Tools is invoked. Users, now when disable it in the config file, the tool will be disabled. Thanks to bendlas@github for narrowing it down. The GUI configuration tool has been improved, thanks to Juan. And there is a new power saving module for users with ATI Radeon cards. Thanks to M. Ziebell for submitting the patch. Laptop Mode Tools development can be tracked @ GitHub

Categories:
Debian-Blog
Computing
Tools

Keywords:
laptop-mode-tools

RHUT

I am very pleased to announce the release of apt-offline, version 1.5. In version 1.4, the offline bug report functionality had to be dropped. In version 1.5, it is back again. apt-offline now uses the new Debian native BTS library. Thanks to its developers, this library is much more slim and neat. The only catch is that it depends on the SOAPpy library which currently is not stock in Python. If you run apt-offline of Debian, you may not have to worry as I will add a Recommends on that package. For users using it on Microsoft Windows, please ensure that you have the SOAPpy library installed. It is available on pypi. The old bundled magic library has been replaced with the version of python magic library that Debian ships. This library is derived from the file package and is portable on almost all Unixes. For Debian users, there will be a Recommends on it too. There were also a bunch of old, outstanding, and annoying bugs that have been fixed in this release. For a full list of changes, please refer to the git logs. With this release, apt-offline should be in good shape for the Jessie release. apt-offline is available on Alioth @ https://alioth.debian.org/projects/apt-offline/

Categories:
Debian-Blog
Tools

Keywords:
apt-offline
Offline APT Package Manager

RHUT

apt-offline 1.4 has been released [1]. This is a minor bug fix release. In fact, one feature, offline bug reports (--bug-reports), has been dropped for now. The Debian BTS interface seems to have changed over time and the older debianbts.py module (that used the CGI interface) does not seem to work anymore. The current debbugs.py module seems to have switched to the SOAP interface. There are a lot of changes going on personally, I just haven't had the time to spend. If anyone would like to help, please reach out to me. We need to use the new debbugs.py module. And it should be cross-platform. Also, thanks to Hans-Christoph Steiner for providing the bash completion script. [1] https://alioth.debian.org/projects/apt-offline/

Categories:
Debian-Blog
Tools

Keywords:
apt-offline
Offline APT Package Manager
offline package manager

RHUT

Fibre Channel over Ethernet (FCoE) is a computer network technology that encapsulates Fibre Channel frames over Ethernet networks. This allows Fibre Channel to use 10 Gigabit Ethernet networks (or higher speeds) while preserving the Fibre Channel protocol. The specification was part of the International Committee for Information Technology Standards T11 FC-BB-5 standard published in 2009 (As descripted on Wikipedia) I just orphaned the FCoE packages for Debian. I don't really have the time and enthusiasm to maintain FCoE any more. The packages may not be in top notch shape, but FCoE as a technology, itself did not see many takers. The popcon stats are low. In case anyone is interested to takeover the maintenance, there is a pkg-fcoe group on alioth. There are 4 packages that build the stack: lldpad, libhbaapi, libhbalinux and fcoe-utils.

Categories:
Debian-Blog

Keywords:
fcoe

RHUT

I am very pleased to announce the release of Laptop Mode Tools, at version 1.65 This release took a toll given things have been changing for me, both personally and professionally. 1.64 was released on September 1st, 2013. So it was a full 9 month period, of which a good 2-3 months were procrastination. That said, this release has some pretty good bug fixes and I urge all distribution packagers to push it to their repositories soon. While I'd thank all contributors who have helped make this release, a special thank you to Stefan Huber. Stefan found/fixed many issues, did the messy code clean up etc.. Thank you. Worthy changes are mentioned below. For full details, please refer to the git commit logs. 1.65 - Wed Jun 18 19:22:35 IST 2014
* fix grep error on missing $device/uevent
* ethernet: replace sysfs/enabled by 'ip link down'
* wireless-iwl-power: sysfs attr enbable -> enabled
* wireless-iwl-power: Add iwlwifi support
* Use Runtime Power Managemet Framework is more robust now. Deprecates module
usb-autosuspend
* Fix multiple hibernate issue
* When resuming, run LMT in force initialization mode
* Add module for Intel PState driver
* GUI: Implement suspend/hibernate interface

Categories:
Debian-Blog
Technology
Tools

Keywords:
laptop-mode-tools

RHUT

Starting yesterday, I am a happy user of the Basis B1 (Carbon Edition) Smart Watch The company recently announced being acquired by Intel. Overall I like the watch. The price is steep, but if you care of a watch like that, you may as well try Basis. In case you want to go through the details, there's a pretty comprehensive review here. Since I've been wearing it for just over 24hrs, there's not much data to showcase a trend. But the device was impressively precise in monitoring my sleep.

Pain points - For now, sync is the core of the pains. You need either a Mac or a Windows PC. I have a Windows 7 VM with USB Passthru, but that doesn't work. There's also an option to sync over mobile (iOS and Android). That again does not work for my Chinese Mobile Handset running MIUI.

Categories:
Debian-Blog
Technology

Keywords:
Basis B1

RHUT

I just released Laptop Mode Tools @ version 1.64. And am pleased to introduce the new graphical utility to toggle individual power saving modules in the package.

The GUI is written using the PyQT Toolkit and the options in the GUI are generated at runtime, based on the list of available power saving modules. Apart from the GUI configuration tool, this release also includes some bug fixes:

Don't touch USB Controller power settings. The individual devices, when plugged in, while on battery, inherit the power settings from the USB controller
start-stop-programs: add support for systemd. Thanks to Alexander Mezin
Replace hardcoded path to udevadm with "which udevadm". Thanks to Alexander Mezin
Honor .conf files only. Thanks to Sven K hler
Make '/usr/lib' path configurable. This is especially useful for systems that use /usr/lib64, or /lib64 directly. Thanks to Nicolas Braud-Santoni
Don't call killall with the -g argument. Thanks to Murray Campbell
Fix RPM Spec file build errors

The Debian package will follow soon. I don't intend to introduce a new package for the GUI tool because the source is hardly 200 lines. So the dependencies (pyqt packages) will go as Recommeds or Suggests

Categories:
Debian-Blog
Tools

Keywords:
laptop-mode-tools

RHUT

The power consumption on the Linux kernel 3.10 is pretty bad. On kernel 3.10, with the follwing config, the PowerTop results are:

# Timers subsystem

CONFIG_TICK_ONESHOT=y

CONFIG_NO_HZ_COMMON=y

# CONFIG_HZ_PERIODIC is not set

CONFIG_NO_HZ_IDLE=y

# CONFIG_NO_HZ_FULL is not set

CONFIG_NO_HZ=y

CONFIG_HIGH_RES_TIMERS=y

PowerTOP v2.0 Overview Idle stats Frequency stats Device stats Tunables

The battery reports a discharge rate of 28.0 W

The estimated remaining time is 23 minutes

Summary: 1785.5 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and 22.1% CPU use

Power est. Usage Events/s Category Description

16.3 W 2915 rpm Device Laptop fan

5.11 W 100.0% Device USB device: WALTON Primo-X1 Primo-X1

1.70 W 33.3% Device Display backlight

849 mW 33.3% Device Display backlight

425 mW 86.0 ms/s 330.7 Process /usr/bin/konsole

316 mW 63.9 ms/s 66.1 Process /usr/bin/plasma-desktop

142 mW 28.6 ms/s 396.8 Process /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7

64.1 mW 13.0 ms/s 198.4 Process kwin -session 101261418fe3000136103713100000053880000_13746081

53.6 mW 10.8 ms/s 0.00 Process powertop

35.9 mW 7.3 ms/s 66.1 Process /usr/lib/chromium/chromium --type=plugin --plugin-path=/usr/li

24.3 mW 4.9 ms/s 396.8 Interrupt PS/2 Touchpad / Keyboard / Mouse

6.92 mW 1.4 ms/s 0.00 Interrupt [48] i915

5.94 mW 1.2 ms/s 66.1 Interrupt [9] RCU(softirq)

3.98 mW 0.8 ms/s 0.00 kWork flush_to_ldisc

3.78 mW 0.8 ms/s 66.1 Process [ksoftirqd/2]

3.33 mW 673.3 us/s 66.1 Process [rcu_sched]

1.80 mW 363.1 us/s 66.1 Interrupt [1] timer(softirq)

1.79 mW 363.0 us/s 0.00 Process [ksoftirqd/4]

Where as on the 3.9 kernel:

The battery reports a discharge rate of 13.2 W

The estimated remaining time is 43 minutes

Summary: 611.5 wakeups/second, 0.0 GPU ops/second, 0.0 VFS ops/sec and 14.2% CPU use

Power est. Usage Events/s Category Description

14.0 W 2722 rpm Device Laptop fan

1.72 W 33.3% Device Display backlight

862 mW 33.3% Device Display backlight

255 mW 65.7 ms/s 58.0 Process /usr/bin/plasma-desktop

91.9 mW 23.7 ms/s 27.5 Process /usr/lib/chromium/chromium --type=renderer --lang=en-US --forc

60.1 mW 15.5 ms/s 96.1 Process /usr/lib/chromium/chromium --type=plugin --plugin-path=/usr/li

25.0 mW 6.4 ms/s 25.1 Process kwin -session 101261418fe3000136103713100000053880000_13746094

21.5 mW 5.6 ms/s 34.2 Process /usr/bin/X :0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7

13.1 mW 3.4 ms/s 5.6 Process /usr/bin/konsole

9.82 mW 2.5 ms/s 53.7 Process [irq/48-iwlwifi]

9.11 mW 2.4 ms/s 2.2 Process /usr/bin/knemo

8.62 mW 2.2 ms/s 12.3 Process /usr/lib/chromium/chromium --password-store=detect

8.32 mW 2.1 ms/s 45.5 Interrupt [48] iwlwifi

6.96 mW 1.8 ms/s 35.3 Interrupt [7] sched(softirq)

5.13 mW 1.3 ms/s 57.1 Interrupt [47] i915

4.24 mW 1.1 ms/s 0.4 Process powertop

3.38 mW 0.9 ms/s 1.5 Timer tcp_keepalive_timer

2.85 mW 0.7 ms/s 11.9 Process /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plu

Categories:
Debian-Blog
Computing
</section><section class="field field-name-taxonomy-vocabulary-2 field-type-taxonomy-term-reference field-label-above view-mode-rss">

Keywords:
laptop-mode-tools
linux
</section>
RHUT

As someone who learned computers on his own, I always acknowledged the value that the Free Software movement has brought. The accessibility of these topics, which are only supposed to be part of text books and schools, is available for anyone and everyone who has the resource and passion to do it. But this past week, 2 things made me pretty impressed with the maturity and quality of work that we do.

rrs@zan:/media$ sudo lvextend -r -v -L 100G /dev/BackupDisk/DATA

Finding volume group BackupDisk

Executing: fsadm --verbose check /dev/BackupDisk/DATA

fsadm: "ext4" filesystem found on "/dev/mapper/BackupDisk-DATA"

fsadm: Skipping filesystem check for device "/dev/mapper/BackupDisk-DATA" as the filesystem is mounted on /media/DATA

fsadm failed: 3

Archiving volume group "BackupDisk" metadata (seqno 7).

Extending logical volume DATA to 100.00 GiB

Found volume group "BackupDisk"

Loading BackupDisk-DATA table (254:2)

Suspending BackupDisk-DATA (254:2) with device flush

Found volume group "BackupDisk"

Resuming BackupDisk-DATA (254:2)

Creating volume group backup "/etc/lvm/backup/BackupDisk" (seqno 8).

Logical volume DATA successfully resized

Executing: fsadm --verbose resize /dev/BackupDisk/DATA 104857600K

fsadm: "ext4" filesystem found on "/dev/mapper/BackupDisk-DATA"

fsadm: Device "/dev/mapper/BackupDisk-DATA" size is 107374182400 bytes

fsadm: Parsing tune2fs -l "/dev/mapper/BackupDisk-DATA"

fsadm: Resizing filesystem on device "/dev/mapper/BackupDisk-DATA" to 107374182400 bytes (13107200 -> 26214400 blocks of 4096 bytes)

fsadm: Executing resize2fs /dev/mapper/BackupDisk-DATA 26214400

resize2fs 1.42.5 (29-Jul-2012)

Filesystem at /dev/mapper/BackupDisk-DATA is mounted on /media/DATA; on-line resizing required

old_desc_blocks = 4, new_desc_blocks = 7

The filesystem on /dev/mapper/BackupDisk-DATA is now 26214400 blocks long.

I didn't have much hope that this extend operation would succeed. But it did. When I initiated this operation, in the background, I had the backups being synced parallely (which actually made me resize my volume. :-)

The other item which made me happy yesterday was Audacity. Once upon a time, when I needed to split a music file to cut a ringtone out of it, I'd go looking for software that could do it. Then I would hope that one of those software vendors have a fully working version and not a demo with just 5 seconds clipping. Cowon was one media player I can recollect I've used to split audio files.

But in this case, I had a different requirement. I needed to increase the dB of my ringtone file so that it sounded really a ringtone (Example: Bourne Ultimatum OST). Audacity, not only did it do the job, it did it for me in just 3-5 minutes. And all with just button clicks. For a n00b with no experience in that domain, I was really impressed.

Categories:

Keywords:

It is still 2012 in this part of the world and the world is still intact. Since nothing major happened, I thought of spending the new gifted time to add a long pending item to apt-offline. As shown in the screen shots, apt-offline's GUI now has support to detect and display the downloaded offline bug reports.

This is part of the just released, version 1.3.

Categories:

Keywords:

I recently switched to a ThinkPad W530 laptop. It is a fairly recent machine with the following hardware config:

Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
8 GiB RAM
nVIDIA Optimus
Samsung SSD Drive

On the software front, I decided to take my chances. Hence:

BTRFS File System
SystemD Init

The rest is in the video. It is impressive to see how drastically the experience has changed with this combination.

From my limited time spent exploring the machine, all credit goes to the SSD technology.

Categories:

Keywords:

Hello World. This is the follow-up to the last 2 updates on the state of apport in Debian.

A lot has changed since the last update on Apport. Currently, in Experimental, we have version 2.6.1-2. With this version, and going forward, there will be no hacks to make it work for Debian. Thanks to Martin Pitt, with his assistance, Apport now has a very basic crashdb in place for Debian. The Debian crashdb provides Apport the interface to interact with the Debian BTS.

This change is already upstream as part of the 2.6.1 release. So for Debian, the packaging is a mere change of the crashdb from 'default' to 'debian'. Being Just Another CrashDB inside Apport, it leverage full support of future Apport releases, fixes and enhancements.

I would like to highlight some points, and some concerns, I have heard in my previous blog posts.

Direct email reports to the developer: This was a concern from the last blog post. There will be no such pop-up anymore. It has been knocked off.
Useless/Incomplete bug reports: With no proper backtrace, it is worried that the bug report will be useless. Apport has intellignece to check if the backtrace is complete. If it is not, it will not report the bug.

Opt-Out: What if the maintainer is not interested in apport reports? The maintainer can ship a blacklist hook into /etc/apport/blacklist.d/. See /etc/apport/blacklist.d/README.blacklist for details.

Categories:

Keywords:

This is a follow up to the previous post regarding Reporting bugs with ApportApport, version 2.2.3-2, has been pushed to experimental. There were some nice feedback that led to some more changes that I will talk here.Opt out: As a developer, if you see the volume of reports to be annoying, you have the option to opt out of apport reports. To do this, you should specify the XBS-Apport: No field in your package's control file. When your application crashes, apport first checks for that field in your package's description and acts based on what you chose.Following image is that the user sees for packages where the developer has opted out. opt out

Repetition: Repetition of the same crash could lead to multiple reports on the same buggy behavior. For this, apport, if senses that you have already filed a bug, it provides you with the option to further ignore all crashes for that particular type.Following image should explain it better. ignore report

My initial thought regarding defaults was to make apport a default opt out tool for the entire archive and only file reports for packages where the developer has manually enabled to opt-in for apport reports. But that'd have been very slow in terms of adoption, hence, for now, instead, the version in experimental does it the other way around. It will file bug reports for all packages. If you need to opt out, you will have to add the above expalined control field. That's it for this post. Please provide feedback once you spend some time with apport.PS: Please take conscious steps when filing bug reports with apport. I think it is a great tool. It just needs great users. :-)

Categories:

Keywords:

So yet another bug reporting tool. :-)When I prepared Apport for Debian, I wasn't sure how it will look going forward. If you look at the current one lying in experimental, it just detects your crashes and pops up in your systray. It doesn't have the mechanism to interact with BTS.So, like the title of this post says, this is the first worthy feature for Apport in the context of Debian. Apport Detail Report

Nothing special here. You would have seen a similar window before if you have installed apport. What changes with this release is, that now, when you check the Send an error report to help fix this problem, it will really file a bug report on the BTS.Here's what the emailed bug report will look like:

Package: leafnode
Version: 2.0.0.alpha20090406a-1
=============================
ProblemType: Crash
Architecture: amd64
Date: Tue Jul  3 00:08:02 2012
Dependencies:
 adduser 3.113+nmu3
 base-passwd 3.5.24
 cron 3.0pl1-123
 debconf 1.5.44
 debianutils 4.3.1
 dpkg 1.16.4.3
 gcc-4.7-base 4.7.1-2
 libbz2-1.0 1.0.6-3
 libc-bin 2.13-33
 libc6 2.13-33
 libclass-isa-perl 0.36-3
 libdb5.1 5.1.29-4
 libfile-copy-recursive-perl 0.38-1
 libgcc1 1:4.7.1-2
 libgdbm3 1.8.3-11
 liblzma5 5.1.1alpha+20120614-1
 libpam-modules 1.1.3-7.1
 libpam-modules-bin 1.1.3-7.1
 libpam-runtime 1.1.3-7.1
 libpam0g 1.1.3-7.1
 libpcre3 1:8.30-5
 libpopt0 1.16-7
 libselinux1 2.1.9-5
 libsemanage-common 2.1.6-6
 libsemanage1 2.1.6-6
 libsepol1 2.1.4-3
 libswitch-perl 2.16-2
 libustr-1.0-1 1.0.4-3
 libwrap0 7.6.q-23
 logrotate 3.8.1-4
 lsb-base 4.1+Debian7 [modified: lib/lsb/init-functions]
 multiarch-support 2.13-33
 netbase 5.0
 openbsd-inetd 0.20091229-2
 passwd 1:4.1.5.1-1
 perl 5.14.2-12
 perl-base 5.14.2-12
 perl-modules 5.14.2-12
 sensible-utils 0.0.7
 tar 1.26-4
 tcpd 7.6.q-23
 update-inetd 4.43
 zlib1g 1:1.2.7.dfsg-13
Disassembly:
 => 0x7f8e69738475 <*__GI_raise+53>:	cmp    $0xfffffffffffff000,%rax
    0x7f8e6973847b <*__GI_raise+59>:	ja     0x7f8e69738492 <*__GI_raise+82>
    0x7f8e6973847d <*__GI_raise+61>:	repz retq 
    0x7f8e6973847f <*__GI_raise+63>:	nop
    0x7f8e69738480 <*__GI_raise+64>:	test   %eax,%eax
    0x7f8e69738482 <*__GI_raise+66>:	jg     0x7f8e69738465 <*__GI_raise+37>
    0x7f8e69738484 <*__GI_raise+68>:	test   $0x7fffffff,%eax
    0x7f8e69738489 <*__GI_raise+73>:	jne    0x7f8e697384a2 <*__GI_raise+98>
    0x7f8e6973848b <*__GI_raise+75>:	mov    %esi,%eax
    0x7f8e6973848d <*__GI_raise+77>:	nopl   (%rax)
    0x7f8e69738490 <*__GI_raise+80>:	jmp    0x7f8e69738465 <*__GI_raise+37>
    0x7f8e69738492 <*__GI_raise+82>:	mov    0x34e97f(%rip),%rdx        # 0x7f8e69a86e18
    0x7f8e69738499 <*__GI_raise+89>:	neg    %eax
    0x7f8e6973849b <*__GI_raise+91>:	mov    %eax,%fs:(%rdx)
    0x7f8e6973849e <*__GI_raise+94>:	or     $0xffffffff,%eax
    0x7f8e697384a1 <*__GI_raise+97>:	retq
DistroRelease: Debian 7.0
ExecutablePath: /usr/sbin/fetchnews
ExecutableTimestamp: 1265584779
Package: leafnode 2.0.0.alpha20090406a-1
PackageArchitecture: amd64
ProcCmdline: /usr/sbin/fetchnews
ProcCwd: /
ProcEnviron:
 LANGUAGE=en_US:en
 LC_TIME=en_IN.UTF-8
 LC_MONETARY=en_IN.UTF-8
 PATH=(custom, no user)
 LC_ADDRESS=en_IN.UTF-8
 LANG=en_US.UTF-8
 LC_TELEPHONE=en_IN.UTF-8
 LC_NAME=en_IN.UTF-8
 SHELL=/bin/sh
 LC_MEASUREMENT=en_IN.UTF-8
 LC_NUMERIC=en_IN.UTF-8
 LC_PAPER=en_IN.UTF-8
ProcMaps:
 00400000-00421000 r-xp 00000000 08:06 4464934                            /usr/sbin/fetchnews
 00621000-00622000 rw-p 00021000 08:06 4464934                            /usr/sbin/fetchnews
 00622000-00623000 rw-p 00000000 00:00 0 
 00be4000-00c05000 rw-p 00000000 00:00 0                                  [heap]
 7f8e68edc000-7f8e68eef000 r-xp 00000000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e68eef000-7f8e690ee000 ---p 00013000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e690ee000-7f8e690ef000 r--p 00012000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e690ef000-7f8e690f0000 rw-p 00013000 08:06 1179776                    /lib/x86_64-linux-gnu/libresolv-2.13.so
 7f8e690f0000-7f8e690f2000 rw-p 00000000 00:00 0 
 7f8e690f2000-7f8e690f7000 r-xp 00000000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e690f7000-7f8e692f6000 ---p 00005000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e692f6000-7f8e692f7000 r--p 00004000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e692f7000-7f8e692f8000 rw-p 00005000 08:06 1180036                    /lib/x86_64-linux-gnu/libnss_dns-2.13.so
 7f8e692f8000-7f8e692fa000 r-xp 00000000 08:06 1183392                    /lib/libnss_mdns4_minimal.so.2
 7f8e692fa000-7f8e694f9000 ---p 00002000 08:06 1183392                    /lib/libnss_mdns4_minimal.so.2
 7f8e694f9000-7f8e694fa000 rw-p 00001000 08:06 1183392                    /lib/libnss_mdns4_minimal.so.2
 7f8e694fa000-7f8e69505000 r-xp 00000000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69505000-7f8e69704000 ---p 0000b000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69704000-7f8e69705000 r--p 0000a000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69705000-7f8e69706000 rw-p 0000b000 08:06 1180055                    /lib/x86_64-linux-gnu/libnss_files-2.13.so
 7f8e69706000-7f8e69883000 r-xp 00000000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69883000-7f8e69a83000 ---p 0017d000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69a83000-7f8e69a87000 r--p 0017d000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69a87000-7f8e69a88000 rw-p 00181000 08:06 1179700                    /lib/x86_64-linux-gnu/libc-2.13.so
 7f8e69a88000-7f8e69a8d000 rw-p 00000000 00:00 0 
 7f8e69a8d000-7f8e69a95000 r-xp 00000000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69a95000-7f8e69c94000 ---p 00008000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69c94000-7f8e69c95000 r--p 00007000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69c95000-7f8e69c96000 rw-p 00008000 08:06 1180031                    /lib/x86_64-linux-gnu/libcrypt-2.13.so
 7f8e69c96000-7f8e69cc4000 rw-p 00000000 00:00 0 
 7f8e69cc4000-7f8e69cc6000 r-xp 00000000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69cc6000-7f8e69ec6000 ---p 00002000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69ec6000-7f8e69ec7000 r--p 00002000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69ec7000-7f8e69ec8000 rw-p 00003000 08:06 1180047                    /lib/x86_64-linux-gnu/libdl-2.13.so
 7f8e69ec8000-7f8e69ed5000 r-xp 00000000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e69ed5000-7f8e6a0d4000 ---p 0000d000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e6a0d4000-7f8e6a0d5000 r--p 0000c000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e6a0d5000-7f8e6a0d6000 rw-p 0000d000 08:06 1179893                    /lib/x86_64-linux-gnu/libpam.so.0.83.0
 7f8e6a0d6000-7f8e6a112000 r-xp 00000000 08:06 1182916                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7f8e6a112000-7f8e6a312000 ---p 0003c000 08:06 1182916                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7f8e6a312000-7f8e6a313000 rw-p 0003c000 08:06 1182916                    /lib/x86_64-linux-gnu/libpcre.so.3.13.1
 7f8e6a313000-7f8e6a333000 r-xp 00000000 08:06 1180134                    /lib/x86_64-linux-gnu/ld-2.13.so
 7f8e6a503000-7f8e6a507000 rw-p 00000000 00:00 0 
 7f8e6a530000-7f8e6a532000 rw-p 00000000 00:00 0 
 7f8e6a532000-7f8e6a533000 r--p 0001f000 08:06 1180134                    /lib/x86_64-linux-gnu/ld-2.13.so
 7f8e6a533000-7f8e6a534000 rw-p 00020000 08:06 1180134                    /lib/x86_64-linux-gnu/ld-2.13.so
 7f8e6a534000-7f8e6a535000 rw-p 00000000 00:00 0 
 7fffbc06e000-7fffbc08f000 rw-p 00000000 00:00 0                          [stack]
 7fffbc1ff000-7fffbc200000 r-xp 00000000 00:00 0                          [vdso]
 ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
ProcStatus:
 Name:	fetchnews
 State:	S (sleeping)
 Tgid:	6872
 Pid:	6872
 PPid:	6871
 TracerPid:	0
 Uid:	9	9	9	9
 Gid:	9	9	9	9
 FDSize:	64
 Groups:	9 
 VmPeak:	   21440 kB
 VmSize:	   21276 kB
 VmLck:	       0 kB
 VmPin:	       0 kB
 VmHWM:	     984 kB
 VmRSS:	     984 kB
 VmData:	     380 kB
 VmStk:	     136 kB
 VmExe:	     132 kB
 VmLib:	    2132 kB
 VmPTE:	      64 kB
 VmSwap:	       0 kB
 Threads:	1
 SigQ:	0/23227
 SigPnd:	0000000000000000
 ShdPnd:	0000000000000000
 SigBlk:	0000000000000000
 SigIgn:	0000000000000000
 SigCgt:	0000000000000000
 CapInh:	0000000000000000
 CapPrm:	0000000000000000
 CapEff:	0000000000000000
 CapBnd:	ffffffffffffffff
 Cpus_allowed:	f
 Cpus_allowed_list:	0-3
 Mems_allowed:	00000000,00000001
 Mems_allowed_list:	0
 voluntary_ctxt_switches:	6
 nonvoluntary_ctxt_switches:	1
Registers:
 rax            0x0	0
 rbx            0x0	0
 rcx            0xffffffffffffffff	-1
 rdx            0x6	6
 rsi            0x1ad8	6872
 rdi            0x1ad8	6872
 rbp            0x0	0x0
 rsp            0x7fffbc08d4f8	0x7fffbc08d4f8
 r8             0x7f8e6a504700	140249645729536
 r9             0x6d6f642064656966	7885631562835126630
 r10            0x8	8
 r11            0x246	582
 r12            0x0	0
 r13            0x7fffbc08d920	140736348084512
 r14            0x0	0
 r15            0x0	0
 rip            0x7f8e69738475	0x7f8e69738475 <*__GI_raise+53>
 eflags         0x246	[ PF ZF IF ]
 cs             0x33	51
 ss             0x2b	43
 ds             0x0	0
 es             0x0	0
 fs             0x0	0
 gs             0x0	0
Signal: 6
SourcePackage: leafnode
Stacktrace:
 #0  0x00007f8e69738475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
         pid = <optimized out>
         selftid = <optimized out>
 #1  0x00007f8e6973b6f0 in *__GI_abort () at abort.c:92
         act =  __sigaction_handler =  sa_handler = 0x7f8e69850d3d, sa_sigaction = 0x7f8e69850d3d , sa_mask =  __val =  140736348083740, 140249634747968, 0, 0, 140736348084512, 140249631083424, 140249645738440, 0, 4294967295, 206158430232, 1, 6427272, 0, 0, 0, 0 , sa_flags = 1781664242, sa_restorer = 0x1 
         sigs =  __val =  32, 0 <repeats 15 times> 
 #2  0x0000000000416292 in ?? ()
 No symbol table info available.
 #3  0x0000000000411c80 in ?? ()
 No symbol table info available.
 #4  0x0000000000406952 in ?? ()
 No symbol table info available.
 #5  0x00007f8e69724ead in __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbc08d918) at libc-start.c:228
         result = <optimized out>
         unwind_buf =  cancel_jmp_buf =  jmp_buf =  0, 498162418289285118, 4206480, 140736348084512, 0, 0, -498021567843461122, -435434157313288194 , mask_was_saved = 0 , priv =  pad =  0x0, 0x0, 0x418360, 0x7fffbc08d928 , data =  prev = 0x0, cleanup = 0x0, canceltype = 4293472 
         not_first_call = <optimized out>
 #6  0x0000000000402fb9 in ?? ()
 No symbol table info available.
 #7  0x00007fffbc08d918 in ?? ()
 No symbol table info available.
 #8  0x000000000000001c in ?? ()
 No symbol table info available.
 #9  0x0000000000000001 in ?? ()
 No symbol table info available.
 #10 0x00007fffbc08ee96 in ?? ()
 No symbol table info available.
 #11 0x0000000000000000 in ?? ()
 No symbol table info available.
StacktraceTop:
 ?? ()
 ?? ()
 ?? ()
 __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbc08d918) at libc-start.c:228
 ?? ()
ThreadStacktrace:
 .
 Thread 1 (LWP 6872):
 #0  0x00007f8e69738475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
         pid = <optimized out>
         selftid = <optimized out>
 #1  0x00007f8e6973b6f0 in *__GI_abort () at abort.c:92
         act =  __sigaction_handler =  sa_handler = 0x7f8e69850d3d, sa_sigaction = 0x7f8e69850d3d , sa_mask =  __val =  140736348083740, 140249634747968, 0, 0, 140736348084512, 140249631083424, 140249645738440, 0, 4294967295, 206158430232, 1, 6427272, 0, 0, 0, 0 , sa_flags = 1781664242, sa_restorer = 0x1 
         sigs =  __val =  32, 0 <repeats 15 times> 
 #2  0x0000000000416292 in ?? ()
 No symbol table info available.
 #3  0x0000000000411c80 in ?? ()
 No symbol table info available.
 #4  0x0000000000406952 in ?? ()
 No symbol table info available.
 #5  0x00007f8e69724ead in __libc_start_main (main=<optimized out>, argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffbc08d918) at libc-start.c:228
         result = <optimized out>
         unwind_buf =  cancel_jmp_buf =  jmp_buf =  0, 498162418289285118, 4206480, 140736348084512, 0, 0, -498021567843461122, -435434157313288194 , mask_was_saved = 0 , priv =  pad =  0x0, 0x0, 0x418360, 0x7fffbc08d928 , data =  prev = 0x0, cleanup = 0x0, canceltype = 4293472 
         not_first_call = <optimized out>
 #6  0x0000000000402fb9 in ?? ()
 No symbol table info available.
 #7  0x00007fffbc08d918 in ?? ()
 No symbol table info available.
 #8  0x000000000000001c in ?? ()
 No symbol table info available.
 #9  0x0000000000000001 in ?? ()
 No symbol table info available.
 #10 0x00007fffbc08ee96 in ?? ()
 No symbol table info available.
 #11 0x0000000000000000 in ?? ()
 No symbol table info available.
Title: fetchnews crashed with SIGABRT in __libc_start_main()
Uname: Linux 3.4-trunk-amd64 x86_64
UserGroups:

The first 2 lines should be enough for the BTS server to file the bug report to the correct package and against the correct version.If you paid attention in the screen shot and the email report, you will notice that the email report does not include the CoreDump section. This was knocked off intentionally as we currently might not need it. If there is a need, the data is always available on the user's apport database, and the dev/user and seek it on a need basis. But in case, if a day comes when we really want it, that too is possible. The same email report will have the CoreDump seciton with a section like the following:

CoreDump: base64

H4sICAAAAAAC/0NvcmVEdW1wAOx9C0AU1f7/7LLAggirouF7VDQ0xcVXWGqLoq4Kur6KMmV5CoqwwqJYVquggYqhlVm3B3mt7OWlbnXtZeubHtfobc9Lb6xUemiU5f7PmfkcmBl3VMzbvff3Px89fPb7nfOeM2fOOfOdMzeNT5pgNBgEBpMwRmiRBMEmnA6bEC8MbfYvI6eN4BePBfvX0zQC6Q9RJyULY6NKpuGC6A8rO56uE07wH44lI7YynINlc6cmnFE3n1L5nNB7j+Ssv8lPelbDaeEkuBCu8ag6HENjz9PCmZTh6sNz/aanVz4PS6+V4aoQTohQhxM1rK2XGoQTI/yn5xD814sX4VyacGerFxbOObh15atj6Z17OKl89Qjn0Qkn6pSvEeGqB59z+YKU4aqmtS6fQgDS0wlXo5NPC8I5HK07DyyczdW68yCy9FytK58V4Zw64eou8l8+G8JZy/2Xj51Abfmaw21Th7Np+LTrD+Fc21p5/SGcRxPOoX8dye0T4ep00vPotU92Hh5u3Xln4Wwvt6587A7jaGU4C8I5X/afz3qd/pqFs73WuutWZOm91rr20hzuu9aVz4pwru9adz3YEM6jE65Op3wOdh6OtO68s3C2tgtaVT4nS+/cw0nlc7H61AnnDfBfPg/Cie0WnOv5C1KFi2tdPqsQzqoTTtAZ91SzcI4Frepf6tlIbeaCc71PyyECcXxm686fBeGsrQwnIpytleGsCFcX9IJPVT6jmrXnwRHM2q863NnOn5MNbJ0+irOFo2EcBjn8uGkzxgvN/ZuMID8t7lAXQXiPuHfhLjTE983qMmswAVVmhpydm5UpZhYsEiaq254PCFLkW8nfQF9cViT1HUM18Te9LefjEhahJv6zgV3DtI7LMaJhdSzMwMFo+cIIgdPWbXaWOyMnP2tpEbwPLi4qHFyUnps/uPmI+EfqOhBD/SBF3nq19J1S+VmT8Z389iVVm8CBdhAzwQHNl 7xNNReLV6SpPH/NUzH0OWZNHkPAVYPl+Npo9GEaua1GDtfIF2ni7wz+5QP5fOOOIXxxTJYjWPgP/bfLQHSLRkUd3hTgv749PWm7FP7r0FcDP15U/cmO9fL4jLFNgzkaiBr4zwWL//QaYtey3vH/NtBrxEbbBHFJk6bOTuFt4v9cmwj4N/vn4ODg4ODg4ODg4OD4/wE3aZ7/G/H8n60B2aDfFmVs9kOf/5vJ325CV2n+HSgol59tKvYiasZmxRzNJCeIhG0q7gY1Y4OCA1UlsKl4b5hRxWxhu2Vdmq0Dp6vYi8UxS5SgCmdEuBiEi4F

Now, Is this going to be useful? Will we get flooded with bug reports?

Usefulness: I think this will uncover many bugs that might be getting unnoticed today. Take this example itself. This bug was detect against the leafnode package's fetchnews binary. That binary does a quiet job in the background, fetching news. I never was aware that it had been crashing. As a system-wide monitoring tool, apport was able to detect, trap and inform the user of the crash. So I think this will be useful and improve the overall quality.

Abuse/Flood: This is something I can't predict. Perhaps it will bring in challenges if people just blindly click on the Send Report button. One option can be to have the "Send Report" checkbox unchecked by default. That'll hopefully lower down the possibilities.

What do you think? Let me know your comments.

This change will soon be pushed to apport in experimental. Hopefully this weekend.

I want to wrap up this post with a Thank You note to Martin Pitt and his team who created Apport, and with such simplicity. It took me 30 lines of code to adapt it to Debian. My intent with Apport is to keep the changes to the minimum so that we can always leverage new features and fixes that Apport brings in. So, as far as I'll try, there will be no drift from its original shape.

Categories:

Keywords:

Laptop Mode Tools, version 1.61, has been released and will land up soon for Debian. This is the version that would be targetting Wheezy.
This release includes many bug fixes and should make power savings much better on your machines.

This is mainly a bug fix release. Some parallel module execution approach has been used which could show runtime improvements.

Changelog:

1.61 - Thu May 17 17:44:26 IST 2012
* Handle devices with persistent device naming. This fixes the issues where
you don't have a disk referenced by a block name, the commit= value was
completely skipped
* Fix issue where hdparm skips SSDs for power management
* Add parallel execution for the modules. In theory this should speeden up the
execution. See git commit log comments for details
* Add support for non-deafult customized settings
* calculate design_capacity_warning on machines/arches where it is not readily
available

We have switched the SCM to git. The current code repository is
available at [1] along with the changelog.

The tarball is available here [2].
The md5 checksum for the tarball is 6685af5dbb34c3d51ca27933b58f484e

[1] https://github.com/rickysarraf/laptop-mode-tools
[2]http://samwel.tk/laptop_mode/tools/downloads/laptop-mode-tools_1.61.tar.gz

Categories:

Keywords:

Now these are the kind of moves that needs to happen more often. Whether this will cause a negative impact on the overall market, and the further invention of drugs (including patent control), but the affordability of the medicatoin to an average citizen is a great move.The typical Chemotherapy can be on an average of 22 times. When summed up with the dosage (somewhere around 250 mg IIRC), the cost comes to approx: (22/4) * 15000 = 82k, which now, will be affordable at 27k.I guess the price slash is only for India and am not sure what the impact to the global market will look like.Quoting the article: http://www.moneycontrol.com/news/business/cipla-drug-price-cut-not-to-hurt-revenue-much-say-analysts_700380.html

Cipla cut price of its kidney cancer drug Sorafenib, which is sold under brand name Nexavar by multi-national Bayer to Rs 6,840 for a month's supply, from around Rs 28,000 earlier. Its lung cancer drug Gestinib, which is sold under brand name Iressa by AstraZeneca will cost Rs 4,250, versus Rs 10,200 earlier, and price of Temozolamide used to treat brain tumour, has been reduced by Rs 15,000 to Rs 5,000.
India's Patent Office recently issued a compulsory licence allowing Natco to make a generic copy of Sorafenib, on the payment of a royalty to Bayer, which sells the drug at around Rs 2 lakh.
Domestic sales account for 46-47% of Cipla's total sales and of that the cancer drugs portfolio is a very small portion, so these price cuts are unlikely to have any major impact on its revenue, Hitesh Mahida of Fortune Equity Brokers told moneycontrol.com
"Cipla's idea seems to be to create disruption in the market, increase its market share..." the analyst says.
Swiss pharma major Roche had earlier this year signed a manufacturing deal with India's Emcure Pharma so that its anti-cancer drugs Herceptin and MabThera could be made in India at affordable prices. Analysts say Cipla's move to slash prices could in future deter some MNCs from launching their drugs in India at all, but some may also look at doing deals like the one struck by Roche.
Meanwhile, shares of pharma major Cipla surged over 3% on Friday after brokerage CLSA upgraded the stock to "outperform" from "underperform," saying, Cipla would be strongest beneficiaries of a weakening rupee.
The rupee has been sliding sharply against the US dollar in recent days and hit over four month low of around Rs 53.78 earlier in trade.
"We expect improving margins over the coming quarters on back of a weak rupee and a low base. We expect strong operating profit growth over coming quarters led by margin expansion and high margin product supplies," CLSA's Hemant Bakhru said.
The US Food and Drugs Administration has approved Meda's drug Dymista for allergic rhinitis and the product is widely expected to reach USD 300-500 million in annual sales over the coming years. The analyst says Cipla being a partner, will benefit through product supplies over a longer term.
"Apart from approval (outside North America) related milestone payment (US$5m), we expect gradual increase in Cipla s sales from product related supplies to Meda. Assuming Cipla supplies product at 10-15% of sales, it could earn US$50-75m at peak sales," Bakhru said.
Additionally, a low base in domestic formulations could result in reasonable India growth, he adds.
Cipla shares were up 2.8% at Rs 326.60 on NSE in noon trade.

Categories:

Keywords: